fix(app-shell): render the envelope's producer-marked userMessage in the Studio package lookup - #7960

Fixes #7938

fetchFullPackage reads the ADR-0112 failure envelope for the words it shows the author,
and read only error.message and error.code. The platform's package door also emits
error.userMessage — the text a producer marked at throw time as addressed to the end
user. This teaches the reader to prefer it.

Verified on the shipping tree at 15c57f85a.

The field really does arrive — measured in the producer, not assumed

The card's evidence chain has a leg in another repo, so it was checked before a line was
written. GET /api/v1/packages is served by the direct-mount registrar,
packages/rest/src/package-routes.ts. Its sendThrownError withholds the prose in the
5xx band:

const thrown = resolveThrownHttpError(error);
// The dispatcher twin's expression, byte for byte — one rule, two doors.
const message = thrown.status >= 500 && looksLikeInternalErrorLeak(thrown.message)
  ? INTERNAL_ERROR_MESSAGE
  : thrown.message;

and then spreads the marked channel onto the wire beside that local, untouched by it:

const extra = {
  ...(thrown.details ? { details: thrown.details } : {}),
  ...(declaredCode !== undefined ? { declaredCode } : {}),
  ...(thrown.userMessage !== undefined ? { userMessage: thrown.userMessage } : {}),
};

That door's own note states the rule, and it is the answer to the question the card asked:

⚠️ NOT withheld on the sanitised 5xx above, and this one needs no judgement call: the
withhold rewrites a LOCAL message const, and looksLikeInternalErrorLeak is only ever
handed thrown.message, so thrown.userMessage is never an input to it. A marked text
is the producer's deliberate statement to the caller at any status — the ruling that
created the channel made it status-agnostic on purpose.

sendError (packages/types/src/response-envelope.ts) nests extra under error:

res.status(status).json({ success: false, error: { code, message, ...extra } });

which is exactly the error.userMessage path this PR reads. The framework pins the pair
in packages/rest/src/package-door-user-message.test.ts §4, asserting
error.message === INTERNAL_ERROR_MESSAGE and the marked text intact on the same body.

So the premise holds: in the 5xx band message is replaced by the generic sentence and
userMessage is not withheld with it. No cross-repo change is produced by this PR; the
framework was read only.

Why userMessage outranks message, and why not only in the 5xx band

The priority is the contract's. The envelope writer's own words:

the text a producer marked, AT THROW TIME, as addressed to the END USER. Presence IS the
marking — a consumer that sees the field renders it verbatim and keeps its generic
substitution for everything unmarked.

The card offered a 5xx-only variant. It is declined deliberately, and the reason is in the
producing door: it applies no status condition to this channel, on purpose. A consumer
that honoured the mark in one band only would re-create on the reading end precisely the
divergence that door refused to create on the writing end. A 4xx message is already
caller-facing by design — but when a producer also marked a text there, the mark is the
more specific answer to "what should this person read", and the diagnostic it displaces is
not lost to diagnosis: code still travels.

This is also not a tolerant alias ladder. These are two declared fields with different
meanings, not two spellings of one fact.

Three combinations, all pinned

Both fields are optional and independent. The new pin file drives all three, not only the
one that motivated the card — reading only the "both present" case is exactly what let
this survive.

The first row is load-bearing: it is the pin that stops "prefer userMessage" from being
implemented as "read userMessage instead", which would have blanked every refusal
the platform serves today.

code composes orthogonally, and that is pinned too: it is appended to whichever prose
won; it never rescues a body carrying no prose (code alone still yields the bare status);
and a non-string or empty-string userMessage is not a mark, so it falls through to
message. The producer's own declaredUserMessage already applies that non-empty rule —
the reader does not depend on it doing so.

The four callers of this endpoint, named individually

This is a shared read, so the beneficiaries were measured rather than inherited from the
card — and the measurement corrects the card on one point. The card described "four
beneficiaries" of this fix. The four named are the four callers of GET /api/v1/packages
on this surface (which is what the openManage docblock says), and they split two ways:

The first three go through fetchPackages in packages-io.ts, which is
if (!res.ok) throw new Error(...) on the status alone — it never opens the body, so it
has no message to lose and no userMessage to gain. They cannot benefit from an
envelope-reading fix because they do not read the envelope. That is a real and strictly
larger defect, in a different file and outside this card's declared surface, so it is
filed separately as #7959 rather than ridden in here.

fetchFullPackage itself has exactly two callers, and both change:

• The management sheet behind "Package info & settings" (openManage) — a marked
  refusal now reaches the author through this surface's existing objectui#7368 toast on
  the shared studio-package-list sonner id.
• The managed-snapshot refresh (onManageChanged's tail, objectui#7907) — the marked
  sentence travels inside the existing engine.studio.pkg.manageRefreshFailed message.
  Same toast, same shared sonner id, same formatter: one mechanism, not a second. §5
  of the new pin file drives this caller specifically so it is shown, not assumed.

The tail's own behaviour (report, then dismiss the panel) belongs to objectui#7907 and is untouched
here; this PR changes only the words it carries.

Evidence

Reverse validation, direction predicted before running: with the fix reverted (mutation
proven on disk by occurrence count and a blob hash differing from HEAD; restored via
git checkout HEAD -- ... under a trap and proven back by an empty git diff HEAD plus a
blob hash identical to the HEAD blob 79a9cf7f0edc1c40b2c8ffa862b3393484bbed37):

Test Files  1 failed (1)
     Tests  7 failed | 8 passed (15)

The prediction was 8 red; 7 measured. The difference is recorded rather than papered over:
§2's "reports once, on the shared sonner id" asserts the report channel, not the words,
and reverting the read changes only the words. It is annotated in the file as green either
way, and it still does a job no words-pin does — a fix that reached for a second reporting
channel would pass every words-pin and fail that one.

Green on the shipping tree:

Every vitest run reports RUN v4.1.10 /home/user/objectui-issue-7938 — the repository
root, not a package sub-root (objectui#3378's silent-false-green). Type-check non-vacuity
was proven with tsc -p tsconfig.test.json --listFiles: both edited files are in the
4416-file program. Lint narrowing needed no argument — the whole package was scanned, and
both edited files are present in eslint's own 1082-file population with 0 errors and no
new warnings (the changed file's 19 warnings are all pre-existing, none within the added
line range 401–449).

check:eager-closure-budget is NOT MEASURED, not green: it exits 2 declaring its own
prerequisite unmet ("No eager-closure report at apps/console/dist/eager-closure.json, so
no chunk was weighed... This is a broken gauge, not 4 budgets that all passed"). It needs a
console build; CI owns that run.

Clause-② = no

多读一个已经在线上的响应字段并渲染它：不改任何 schema 的接受/拒绝行为，不扩大公开面，不移动任何门的扫描 population。

Generated by Claude Code